Windows Stim loading still failed even when libstdc++-6.dll was found, due to downstream API-set dependency resolution (api-ms-win-core-synch-*). This also raised a packaging concern: plugin-local libstdc++ copies can conflict when multiple plugins are loaded.

• Runtime strategy: eliminate shared MinGW runtime DLL dependence

  • Keep Stim’s windows-gnu build statically linked to C++/gcc runtimes (static=stdc++, -static-libstdc++, -static-libgcc), so plugin loading does not depend on a distributed libstdc++-6.dll.

• Packaging change: stop shipping plugin-local libstdc++-6.dll

  • Removed Windows-specific libstdc++-6.dll copy logic from hatch_build.py for selene_stim_plugin.
  • Removed the now-unused bundle_mingw_runtime_dll(...) helper.

This shifts Windows behavior away from per-plugin runtime DLL distribution and avoids cross-plugin libstdc++ version/collision risk.

// selene-ext/simulators/stim/build.rs (windows-gnu)
println!("cargo:rustc-link-lib=static=stdc++");
println!("cargo:rustc-link-lib=static=winpthread");
println!("cargo:rustc-link-arg=-static-libstdc++");
println!("cargo:rustc-link-arg=-static-libgcc");

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.